Fast forward eight months later to August 2015 and Klopp is thrust into the role of chief information officer, where now he has the budget and authority to turn long-term ideas into short term realities.
“The good thing about starting as CTO is that I was able to kick-off several technical initiatives, and then as CIO I am able to make sure they got funded so there was something fairly useful about that whole thing,” he said. “As CIO, almost the first thing I did was compose, get permission and implement a reorganization of systems. As CIO, I’ve become involved in discussions about transparency into IT budget that I never would’ve gotten into as the CTO. And most importantly as CIO, things like the requirements at SSA to get into things like IT modernization and stuff like that, that require investment and budget funding beyond what we could do on our own, I was probably one of the early people who started advocating for extra money for IT modernization.”
For example, SSA’s major data center consolidation and upgrade is scheduled to be completed in May, coming in ahead of schedule and under budget by about $41 million.
Klopp said he’d like to figure out a way to use that $41 million to modernize other legacy IT systems. He said while no decision has been made about what happens to that extra funding—meaning if SSA can use it or if it goes back to the Treasury—there is no shortage of options and opportunities.
Klopp said among his top priorities is accelerating the use of cloud across SSA starting with developing a data warehouse.
He said it’s not quite software-as-a-service, but SSA built a proof of concept of the data warehouse in the cloud.
“The proof of concept is not a toy because the concept I want to prove is that I can actually deploy this thing in production,” Klopp said. “It will go in production. And while all of this build is going on, we are starting to build the federal procurement RFQ or RFP so somewhere toward the end of this year, I expect we will have to compete all of this infrastructure that we’ve built and it could be that we have to replace the database or replace the cloud with another cloud or maybe replace the cloud with an on premise thing. In the meantime, the way to actually move extremely quickly within the constraints of federal procurement stuff is to move out and get it going in the cloud.”
Klopp said moving the data warehouse into the cloud had its challenges, including getting a security authorization to operate.
“The cloud is as secure or more secure as on premise stuff,” he said. “What we are trying to do now is move through the process to demonstrate that it’s secure and to pass all the gates that we have to pass for every federal application to ensure that level of security. Right now we are tracking on having those authorizations by the end of March. So far we have found no flaws, and in fact, there is a growing sense that the cloud environments provide a level of security that you can’t provide so easily on an on-premise implementation. So data warehouse in the cloud is a start and we will see where it goes to after we compete the infrastructure in an open federal competition.”
Klopp said along with creating a data warehouse and moving the infrastructure to the cloud, he’s improving the processes and capabilities for software development.
He said one way to do that is to put more modern tools in place for the developers. SSA, unlike most agencies, does most—about 75 percent– of its software development in-house with federal employees.
“The best practice in software development is to build a whole series of functions that are orchestrated together whenever a programmer drops new code into the source code library,” Klopp said. “The first thing it does is compile it and tells me if I have any compiler errors. If it compiles cleanly, then the next thing it does is it tries to do some unit testing. If it comes back and says you passed all unit tests, and this goes on and on. I can orchestrate penetration testing to make sure the code I’ve written doesn’t have any cybersecurity leaks in it. At the end of this orchestrated integration environment, I basically know this code is ready to go into production. In a best case scenario, that process might only take an hour or maybe 90 minutes. What happens is programmers check code in and, within 90 minutes, know if anything is wrong.”
He said SSA built an automated environment for JAVA development and is starting to use it on its first project.
He said feedback under SSA’s current development process could take as much as 90 days.
“One of the things I need to do is kind of shake it up a little bit,” Klopp said. “For too many years, we’ve basically told our software engineers they have a choice of COBOL or JAVA, and they have a choice of DB2 on the mainframe or DB2 on the mainframe. They can use WebSphere or WebSphere. What ends up happening is the people who might otherwise say there is some new stuff out there and I’d like to use it, keep being told no.”
“What we need to do there is open up the software engineering world to all of the new tools and capabilities available,” he said. “We have to be careful because there is some tension between letting people do whatever they want and finding yourselves with a whole bunch of secure things you will have to support and maintain. We are starting to have very serious discussions about whether we should consider using some open source tools and open source languages. We are trying to open this up a little bit partly because these new tools are really valuable, and partly because just by opening it up, it creates a whole different attitude among the software engineering community that is really positive.”