“By most metrics, 18F is withering away.”
Original source: The rise and fall of 18F
“By most metrics, 18F is withering away.”
“By most metrics, 18F is withering away.”
Original source: The rise and fall of 18F
“We don’t think that blockchain is the universal solution to the identity problem; however, it certainly provides a missing link by allowing people and organizations to prove things about themselves online, as they do offline, using decentralized and verifiable identifiers. Identity-related information can be looked up (verified) without involving a central directory or paper-based document. Additionally, the identity owner does not need to overshare, and the recipient does not have to store unnecessary sensitive data.”
Original source: The path to self-sovereign digital identity starts with blockchain
Part of the problem, according to the General Services Administration’s Bill Zielinski, is that many agencies still try to scope out modernization projects with highly specific technical requirements. “We define not only the business outcome that we’re trying to achieve,” Zielinski said at the FCW-hosted IT modernization event, “but we have that tendency to say, ‘and this is explicitly how you’re going to do that.'”
Such specific solicitations tend to produce near-identical proposals from industry, he noted, which forces agencies to select based on “lowest price technically acceptable” criteria. Worse, he said, that prescriptive approach denies agencies the opportunity to benefit from new and creative solutions that might surface if they simply described the business capability that’s needed.
“One of the problems that we’ve got — it’s not the problem but it’s a problem — you develop a piece of technology, we don’t have the resourcing flexibility to buy it.”
That means the Army is forced to buy a technology available today it thinks it will need in 2025, when what it truly needs hasn’t been developed yet.
“[Say] you came up with something new that I really need on the battlefield based on a threat, I have no ability to integrate that into my platform. So whether it’s buy, try, decide or adapt and buy, this allows us to test technology, put it in a demonstrative, experimental environment .… Maybe I want to give it to this unit that’s going to this particular place and get feedback, and then I iterate the whole Army.”
In the US, we love arm-chair strategizing government IT, in particular federal IT. Getting your arms around “the problem” is near impossible.
As citizens, our perceptions seem to be that government IT has poor user experience, none at all (there’s no app to do things, you have to go to an office to fill something out, etc.), and that it costs too much. More wonky takes are that there’s not enough data provided, nor insights generated by that data to drive better decision making.
When I’ve spoken with government IT people, their internal needs revolve around increasing (secure) communication, using more modern “white-collar” tools (from simply upgrading their copies of Office, to moving to G Suite/Office 365 suites, or just file sharing), and addressing the citizen perceptions (bringing down costs, making sure the software, whether custom made or “off the shelf,” have better customer experiences.
It’s also easy to think that government is a special snow-flake, but, really, they have mostly the same problems as any large organization. As highlighted below, the government contracting, procurement, and governance processes are more onerous in government IT, and the profile of “legacy” systems is perhaps higher, but, worse, more of a pull down into the muck.
From my conversations, one of the main barriers to change is systemic inertia, seemingly driven by avoidance of risk and overall lack of motivation to do anything. This lack of motivation is likely driven by the lack of competition: unlike in the private sector, there’s no other government to go to, so there’s no fear of loosing “business,” so what care to change or make things better?
Anyhow, here’s a notebook of federal government IT.
Source: “2017 CIO Agenda: A Government Perspective,” Rick Howard, Gartner, Feb. 2017.
If you’re really into this kind of thing, you should come to our free Pivotal workshop day in D.C., on June 7th. Mark Heckler and I will be going over how to apply “cloud-native” thinking, practices, and technologies to the custom written software portion of all this. Also, I’ll be speaking at a MeetUp later that day on the overall hopes and dreams of cloud-native, DevOps, and all that “agile” stuff.
The miniature culture wars fought between cities and states—such as North Carolina’s tussle with Charlotte over its anti-discrimination rules—are well known. The financial tensions between them are quieter but as important. “Money is usually the main problem,” says Larry Jones of the United States Conference of Mayors, and especially divisive in lean times.
In contrast to agile, private-sector companies, the public sector does not face any pressure from competition. When it comes time to renew your license, there is only one place for you to do that: and, unfortunately for Americans, that’s the DMV. With no competitive forces, government agencies do not have to innovate or take bold risks when it comes to digital.
And, as ever, being smart about using updated tools and new methods yield huge productivity results:
While running technology for Obama’s WhiteHouse.gov, open-source solutions enabled our team to deliver projects on budget and up to 75% faster than alternative proprietary-software options. More than anything, open-source technology allows governments to utilize a large ecosystem of developers, which enhances innovation and collaboration while driving down the cost to taxpayers.
While open source has different cost dynamic, I’d suggest that simply switching to new software to get the latest features and mindset that the software imbues gives you a boost. Open source, when picked well, will come with that community and an ongoing focus on updates: older software that has long been abandoned by the community and vendors will stall out and become stale, open or not.
With most large organizations, and especially government, simply doing something will give you a huge boost in all your KPIs in the short term. Picking a thriving, vibrant stack is critical for long term success. Otherwise, five or ten years from now, whether using open or closed source, you’ll end up in the same spot, dead in the water and sucking.
Delivery teams are now able to build services faster and easier. In July 2016, DTA had 14 apps in production and 50 apps in development. In October 2016, the numbers increased to 47 apps in production and 225 apps in development.
If there’s one complaint that I hear consistently in my studies of IT in large organizations, it’s that government IT, as traditionally practiced, is fucked. Compared to the private sector, the amount of paperwork, the role of contractors, and the seeming separation between doing a good job and working software drives all sorts of angst and failure.
Mark Schwartz’s book on figuring out “business value” in IT is turning out to be pretty amazing and refreshing, especially on the topic of government IT. He’s put together one of the better “these aren’t the Droids you’re looking for” responses to ROI for IT.
You know that answer: you just want to figure out the business case, ROI, or whatever numbers driven thing, and all the DevOps-heads are like “doo, doo, doo-doo – driving through a tunnel, can’t hear you!” and then they pelt you with Goldratt and Deming books, blended in with some O’Reilly books and The Phoenix Project. “Also, you’re argument is invalid, because reasons.”
A Zen-like calm comes over them, they close their eyes and breath in, and then start repeating a mantra like some cowl-bedecked character in a Lovecraft story: “survival is not mandatory. Survival is not mandatory. Survival is not mandatory!”
Real helpful, that lot. I kid, I jest. The point of their maniacally confusing non-answers is, accurately, that your base assumptions about most everything are wrong, so before we can even approach something as precise as ROI, we need to really re-think what you’re doing. (And also, you do a lot of dumb shit, so let’s work on that.)
But you know, no one wants to hear they’re broken in the first therapy session. So you have to throw out some beguiling, mind-altering, Lemarchand’s boxes to change the state of things and make sure they come to the next appointment.
Anyhow, back to Schwartz’s book. I’ll hopefully write a longer book review over at The New Stack when I’m done with it, but this one passage is an excellent representation of what motivates the book pelters and also a good unmasking of why things are the way we they are…because we asked for them to be so:
The US government is based on a system of “checks and balances”—in other words, a system of distrust. The great freedom enjoyed by the press, especially in reporting on the actions of the government, is another indication of the public’s lack of trust in the government. As a result, you find that the government places a high value on transparency. While companies can keep secrets, government is accountable to the public and must disclose its actions and decisions. There is a business need for continued demonstrations of trustworthiness, or we might as well say a business value assigned to demonstrating trustworthiness. You find that the government is always in the public eye—the press is always reporting on government actions, and the public is quick to outrage. Government agencies, therefore, place a business value on “optics”—how something appears to the observant public. In an oversight environment that is quick to assign blame, government is highly risk averse (i.e., it places high business value on things that mitigate risk).
And then summarized as:
…the compliance requirements are not an obstacle, but rather an expression of a deeper business need that the team must still address.
Which is to say: you wanted this, and so I am giving it to you.
The word “bureaucracy” is something like the word “legacy.” You only describe something as legacy software when you don’t like the software. Otherwise, you just call it your software. Similarly, as Schwartz outlines, agile (and all software processes) are insanely bureaucratic, full of rules, norms, and other “governance.” We just happen to like all those rules, so we don’t think of them as bureaucracy. As he writes:
While disavowing rules, the Agile community is actually full of them. This is understandable, because rules are a way of bringing what is considered best practices into everyday processes. What would happen if we made exceptions to our rules—for instance, if we entertained the request: “John wants to head out for a beer now, instead of fixing the problem that he just introduced into the build?” If we applied the rules capriciously or based on our feelings, they would lose some of their effectiveness, right? That is precisely what we mean by sine ira et studio in bureaucracy. Mike Cohn, for example, tells us that “improving technical practices is not optional.”15 The phrase not optional sounds like another way of saying that the rule is to be applied “without anger or bias.” Mary Poppendieck, coauthor of the canonical works on Lean software development, uses curiously similar language in her introduction to Greg Smith and Ahmed Sidky’s book on adopting Agile practices: “The technical practices that Agile brings to the table—short iterations, test-first development, continuous integration—are not optional.” I’ve already mentioned Schwaber and Sutherland’s dictum that “the Development Team isn’t allowed to act on what anyone else [other than the product owner] says.”17 Please don’t hate me for this, Mike, Mary, Ken, and Jeff, but that is the voice of the command-and-control bureaucrat. “Not optional,” “not allowed,” – I don’t know about you, but these phrases make me think of No Parking and Curb Your Dog signs.
These are the kind of thought-trains that only ever evoke “well, of course my intention wasn’t the awful!” from the other side. It’s like with the ITIL and the NRA, gun-nut people: their goal wasn’t to put in place a thought-technology that harmed people, far from it.
Gentled nestled in his wry tone and style (which you can image I love), you can feel some hidden hair pulling about the unintended consequences of Agile confidence and decrees. I mean, the dude is the CIO of a massive government agency, so he be throwing process optimism against brick walls daily and too late into the night.
The cure, as ever, is to not only to be smart and introspective, but to make evolution and change part of your bureaucracy:
Rules become set in stone and can’t change with circumstances. Rigidity discourages innovation. Rules themselves come to seem arbitrary and capricious. Their original purpose gets lost and the rules become goals rather than instruments. Bureaucracies can become demoralizing for their employees.
So, you know, make sure you allow for change. It’s probably good to have some rules and governance around that too.
Instead, the post emphasized new ways NASA is thinking about acceptable risk for these launches. During the space shuttle era, launch sites were governed by some 2,200 safety requirements. NASA worked to “strip down the expensive rules and came up with just 500 core safety requirements for launches.”
But, the post notes, ”at commercial launch sites, there are only 55 safety requirements.” This “underscores perhaps the single biggest difference between NASA and its commercial partners: risk tolerance. NASA likes to have next to none, and pays for it, while the companies tend to embrace calculated risk as a way to iterate and learn while still developing their products.”
This a major point in companies fixing up their software process: you probably have all sorts of rules and regulations that no longer apply. Just like with managing a legacy application portfolio, you have to aggressively manage your compliance portfolio to eliminate rules that no longer apply.
Matt Curry covers this point with a funny boat-metaphor at the start of his brand talk from last year. You also hear some cases of federal agencies forcing this culling by simply not following the rules and seeing if anyone complained: the compliance equivilent of just turning off old, dusty servers to see who’s using it.