Melinda Solomon

So this is how to DevOps with auditors in the room.

This is an exploration of an experiment that was undertaken by U.S. Citizenship and Immigration Services. My name is Melinda Solomon, and I'm a contractor for USCIS. I run the Agile Training Program there.

But I really just like to tell stories of things that people are doing that seem really cool, and I get geeked out about things like this.

USCIS's journey to Agile started with the leadership of Mark Schwartz, who was signing books yesterday and also did a presentation on IT leadership. Under his leadership, we moved from 180 days to deliver software to having many teams that can deliver daily, which is pretty outstanding for the federal government.

Every time that we make decisions, we need to all be on the same page. When he suggested that we move to microservices, we needed a common understanding of what that was: small, loosely coupled, language-agnostic, fallible, including configuration settings, and containerized.

But every time we make these kinds of decisions, we need to make sure that everyone's on the same page. We've got business folks, we've got developers, we've got IT governance, and everyone needs to be playing from the same sheet of music.

The IT governance folks want repeatable processes that ensure focus on documented quality, and that's because they need to answer to auditors who want evidence of due diligence. Are people paying attention? Are we making good decisions?

And the reality is that in the federal government, the American public own the systems that we build, and they expect transparency. Those auditing authorities, the oversight folks, help maintain the trust between the citizenry and the public servants, and we don't take that lightly.

At USCIS, we decided to try to manage our microservices by creating this USCIS microservices registry. The registry is sort of a clearinghouse of information about all of the microservices that are created.

As a developer creates a microservice, they also create a virtual index card that gives information about what is this microservice, who built it, and why did they do that? What are they trying to accomplish with this?

When you click on the card, it takes you to a dashboard. The dashboard tells you all of the information that's coming automatically from orchestration tools and testing tools and monitoring tools. That means that auditors and IT oversight and all of these different stakeholders that are interested in what's going on don't need to learn to navigate all of these tools to find the information.

It's all in one place. This allows us to make sure that our static code analysis, for example, is right on track, that we know the attributes of the containers, and that we also know what the security status is, because that's really important in the federal space.

And the nice thing is that it's a low level of effort. The developers just need to create a very simple file, and that allows for a continuous flow of accurate and current data, which means the developers don't have to be curating information for the auditors all the time.

But in order to be really audit-ready, we're not at a point where we're completely automated. We have some pipeline engineers and DevOps folks who are taking a look at all of the microservices, making a yes/no determination on a whole bunch of different factors. And that allows them to identify if there are systemic problems that really shouldn't be addressed by the developers themselves, but instead by IT leadership.

Here we can see that BDD testing, for example, is pink across the board almost. And so maybe there's actually a bigger problem that needs to be addressed from upper management and not the developers themselves.

We can also see if there are specific microservices that are pink across all criteria, which may indicate that that microservice has some issues. And maybe we can learn what are the aspects of that microservice that create these problems so that we don't repeat them in the future.

This transparency allows for autonomy. Our developers can make whatever makes sense for them, and they don't have to constantly be asking for permission to do what they think is the right solution.

That also leads to trust, that they know that the oversight authorities are not just going to try to stop them from doing what they want to do but are actually going to remove impediments.

And the auditors, when they come in, the IT governance folks feel confident that they already know what's going on.

If you want to know more about what USCIS is doing, you're welcome to contact us at the USCIS Agile Training Program, and we'll get all of your questions to the appropriate people.

Thank you so much for your time.