Across the Department of Homeland Security, there are at least seven people with the title chief technology officer.

Unlike agency chief information officers, CTOs have less defined roles and responsibilities.

David Larrimore, the DHS CTO, is trying to change that. He wants to bring more formality to the CTO roles across the department, without making it unnecessarily prescriptive.

“We have a currently more or less than an informal CTO council. It’s informal in the sense that it really is not based upon a charter. There is no authorizing official for document. There’s no authority with the council. We are actually have a draft right now to create  a DHS CTO council,” Larrimore said during a recent webinar sponsored by ACT-IAC, an excerpt of which was played on Ask the CIO. “The concept is the authority from the CIO council will give birth to the CTO council. So as the CIO council is working on a lot of the big picture CIO strategies, we will be focusing on specific areas of technology, modernization, information sharing, agile cloud, DevOps and all of those areas. Essentially, the CTO Council will be responsible for having a consensus on the strategy, and that’s the big thing is we’re looking for is consensus.”

Consensus, Larrimore said, doesn’t mean one cloud to rule them all or one tool all components will be forced to use.

Instead, Larrimore said his goal is to have all of the CTOs across DHS put together a set of technology artifacts that may end up in something like a target architecture or some kind of IT strategy that they all agree to abide by.

“There’s going to be differences because the FEMA mission is different than the TSA mission, which is different than the USCIS mission, which is different than the Secret Service mission. And those differences lead to the need to prioritize standardization and consolidation of specific technologies that may not be relevant to other components. But the idea is, if we all agree upon those artifacts, if we all put together and sign off on those saying that this is our component target architecture, when it comes to those billion dollar programs that are that are coming through the undersecretary for management, which it has oversight over … then I am reinforcing the importance of the component level with the federation that we have across the department,” he said. “I’m building trust amongst the CTOs at all of the components, and I’m also really validating the need for the CTOs in the first place.”

RPA is growing across the agency

Larrimore added that the target architecture would provide components with a base set of concepts for technology whether it’s cloud or analytical tools or whatever and then the CTOs or CIOs can build from and implement to meet their specific mission needs.

“For example, a lot of the components are working very heavily on the concept like robotics process automation (RPA), but CBP is saying that this is clearly providing good to their agency and they want to continue to foster that. So my expectation would be that there should be a technology strategy or target architecture around using robotic process automation that may not be inside of ICE’s target architecture or may not be inside of FLETC’s target architecture, but that first year, it may be only in CBP’s. But then as the CTO council goes around talking about using some RPA technologies here at headquarters so maybe we all agree that maybe we need to provide some consensus around RPA,” he said.

That consensus includes how to manage the technology, who is the owner of the RPA projects within each component and what specific technologies are available to use to implement the automations.

This is how Larrimore sees his job, helping DHS as a whole “see the forest amongst the trees” as the agency moves toward enterprise capabilities and come together around a common technology and mission strategy.

“How are we taking a service delivery approach or service design approach to having cloud services offered for all of our programs?” he said. “The second side is looking at the aspect of components as most of my predecessors in headquarters were predominantly focused on the big kind of DHS picture right there. But headquarters is an IT delivery element, right? How is the chief technology officer at headquarters going to be able to manage all that? Well, I do that by learning from a lot of the components. So I am working very heavily with the component CTOs and taking from my experience prior as the ICE CTO to institute a mature CTO operation up at headquarters.”

Driving IT priorities

The target architecture or IT strategy is part of how Larrimore wants to not only provide credibility for his organization, but drive DHS-wide strategic priorities down to the components.

“In order for me to get there, I need to be able to prove myself amongst them to build and deliver as a component level CTO and be able to listen to them and do what I call being at the bottom of the pyramid versus the top,” he said. “I think the major differences [with agency CIOs is] that the CTO tends to be the incubator of things. The CIO has the total responsibility and oversight of everything from IT operations and development to security and business management and that side of things. That’s where their focus is always going to live. They are going to be driving priorities for the CTO to incubate various things. The CIOs are expecting the CTO to put up governance, best practices, playbooks, all of those types of document that they can provide out, and then that becomes adopted as a standard under the auspices of the CIO.”

Larrimore said he knows getting components to get on the same target architecture will not be as simple as issuing a document and supporting those concepts from the headquarters level.

He said he knows forcing components to adopt the concepts of a target architecture is necessarily going to work without some incentives.

“I have authorities that [other CTOs] may not have and I have oversight responsibilities that they may not have,” Larrimore said. “The second thing is I can use that target architecture to help drive discussions to help ensure that the programs are coordinating with our CIO’s office, which historically has not always been the case. We don’t really have a lot of processes for providing guidance to programs in the need phase, but we’ve got tons them at the analyze and select phases. We have all of our operational processes once the program has met their full operational capabilities, and is in operations and sustainment. But we don’t really have a lot of guidance other than templates to provide programs on the technology and architecture that we want them to start adopting. So in addition to helping to build relationships between the programs and the component technology leadership, it’s also getting early awareness, early transparency on the types of IT procurements are happening and making sure that we have a plan for them.”

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.